This invention relates to a method of handling requests for service by the operating system of a digital computer, such requests being herein referred to as system calls; more particularly, it relates to a method of handling system calls in firmware.
The term firmware refers herein to computer programs and data stored in a memory device such as a read-only memory (ROM) disposed in the central processing unit of the computer. In the case of a single-chip microcomputer, for example, firmware may be stored in an on-chip ROM from which instructions can be fetched and data read at high speed.
The term software herein refers to computer programs and data stored outside the central processing unit, in the computer's main random-access memory (RAM), for example, or an external memory device such as a rotating magnetic disk. In the case of a single-chip microcomputer, software may also be stored in separate ROM chips. In general it takes the central processing unit longer to fetch software instructions and data than firmware instructions and data, so software programs execute-less rapidly than firmware programs.
One of the most important components of a computer's software is its operating system. The operating system performs general control functions, oversees the execution of tasks such as application programs, and provides services which different application programs may use in common. These services are executed by system service routines, which are invoked from application programs by system call instructions.
The operating system comprises a plurality of programs. One of the programs in a typical operating system is a task scheduler, which compares the priority of the tasks currently ready for execution and selects the task with the highest priority. Another is a system call dispatcher, which analyzes system calls and decides which system service routine to execute. The system service routines are of course also part of the operating system.
A typical operating system handles system calls in the following manner. A system call instruction in an application program generates a system call exception which causes the system call dispatcher to begin executing. The system call dispatcher analyzes the system call, determines which system service routine to execute, and branches to the selected system service routine. Execution of this routine provides the service requested by the application program. At the end of the system service routine, the task scheduler is invoked to select the next task. Ultimately control returns from the task scheduler to the application program.
To obtain higher speed, some operating-systems have part of their functions stored in firmware. In the prior art, the operating-system functions stored in firmware commonly comprise the code that generates the system call exception and code used by frequently-called system service routines. System calls for services using code stored in firmware are then handled in the same way as described above, except that the system service routine contains an instruction that branches from the software part of the routine to the firmware code used by the routine, and the firmware code ends by returning to the software part of the routine.
A problem with this scheme for handling system calls in firmware is that even if substantially all of the code of a system service routine is stored in firmware, handling of the corresponding system call still requires extensive execution of operating-system software, including the system call dispatcher and task scheduler. This software overhead unnecessarily delays the operating system's response to the system call.
Another problem is that each time a new system service function is stored in firmware, the operating-system software must be altered so that the software system service routine can branch to the new firmware code. That is, whenever the system firmware is updated, the system software must also be updated. These updates may give the system greater speed, but system maintenance would be more convenient and less expensive if that speed could be obtained by updating the firmware alone, leaving the software in its existing state. This problem is particularly acute in microcomputer systems in which the operating-system software is permanently stored in semiconductor memory chips and cannot readily be altered.